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Abstract 
A mobile node and a correspondent node may preconfigure data useful 
for precomputing a Binding Management Key that can subsequently be 


used for authorizing Binding Updates. 
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1. Introduction 


This specification introduces an alternative, low-latency security 
mechanism for protecting signaling related to the route optimization 
in Mobile IPv6é. The default mechanism specified in [1] uses a 
periodic return routability test to verify both the "right" of the 
mobile node to use a specific home address, as well as the validity 


of the claimed care-of address. That mechanism requires no 
configuration and no trusted entities beyond the mobile node’s home 
agent. 
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The mechanism specified in this document, however, requires the 
configuration of a shared secret between mobile node and its 
correspondent node. As a result, messages relating to the 
routability tests can be omitted, leading to significantly smaller 
latency. In addition, the right to use a specific home address is 
ensured in a stronger manner than in [1]. On the other hand, the 
applicability of this mechanisms is limited due to the need for 
preconfiguration. This mechanism is also limited to use only in 
scenarios where mobile nodes can be trusted not to misbehave, as the 
validity of the claimed care-of addresses is not verified. 


The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. Other 
terminology is used as already defined in [1]. 


2. Applicability Statement 


This mechanism is useful in scenarios where the following conditions 
are all met: 


- Mobile node and correspondent node are administered within the 
same domain. 


- The correspondent node has good reason to trust the actions of 
the mobile node. In particular, the correspondent node needs to 
be certain that the mobile node will not launch flooding attacks 
against a third party as described in [5]. 


- The configuration effort related to this mechanism is acceptable. 
Users MUST be able to generate/select a sufficiently good value 
for Ken (see [3]) 


- There is a desire to take advantage of higher efficiency or 
greater assurance with regards to the correctness of the home 
address offered via this mechanism. 


- This mechanism is used only for authenticating Binding Update 
messages (and not, e.g., data), so the total volume of traffic is 
low (see RFC 4107 [4], and the discussion in section 4). 


This mechanism can also be useful in software development, testing, 
and diagnostics related to mobility signaling. 


Generally speaking, the required level of trust that the 
correspondent node needs for enabling a precomputable Kbm with a 
mobile node is more often found within relatively small, closed 
groups of users who are personally familiar with each other, or who 
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have some external basis for establishing trustworthy interactions. 
A typical example scenario where this mechanism is applicable is 
within a corporation, or between specific users. Application in the 
general Internet is typically not possible due to the effort that is 
required to manually configure the correspondent nodes. Application 
at a public network operator is typically not possible due to 
requirements placed on the trustworthiness of mobile nodes. 


3. Precomputing a Binding Management Key (Kbm) 


A mobile node and a correspondent node may preconfigure data useful 
for creating a Binding Management Key (Kbm), which can then be used 
for authorizing binding management messages, especially Binding 
Update and Binding Acknowledgement messages. This data is as 
follows: 


- A shared key (Kcn) used to generate keygen tokens, at least 20 
octets long 


- A nonce for use when generating the care-of keygen token 
- A nonce for use when generating the home keygen token 


The keygen tokens MUST be generated from Kcn and the nonces as 
specified in Mobile IPv6 [1] return routability. Likewise, the 
binding management key Kbm must subsequently be generated from the 
keygen tokens in the same way as specified in Mobile IPv6 [1]. The 
preconfigured data is associated to the mobile node’s home address. 
Ken MUST be generated with sufficient randomness (see RFC 4086 [3]). 


Replay protection for Binding Update messages using Kbm computed from 
the preconfigured data depends upon the value of the Sequence Number 
field in the Binding Update. If the correspondent node does not 
maintain information about the recently used values of that field, 
then there may be an opportunity for a malicious node to replay old 
Binding Update messages and fool the correspondent node into routing 
toward an old care-of address. For this reason, a correspondent node 
that uses a precomputable Kbm also MUST keep track of the most recent 
value of the Sequence Number field of Binding Update messages using 
the precomputable Kbm value (for example, by committing it to stable 
storage). 
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When a Binding Update is to be authenticated using such a 
precomputable binding key (Kbm), the Binding Authorization Data 
suboption MUST be present. The Nonce Indices option SHOULD NOT be 
present. If it is present, the nonce indices supplied SHOULD be 
ignored and are not included as part of the calculation for the 
authentication data, which is to be performed exactly as specified in 
ELI- 


4. Security Considerations 


A correspondent node and a mobile node may use a precomputable 
binding management key (Kbm) to manage the authentication 
requirements for binding cache management messages. Such keys must 
be handled carefully to avoid inadvertent exposure to the threats 
outlined in [5]. Many requirements listed in this document are 
intended to ensure the safety of the manual configuration. In 
particular, Kcn MUST be generated with sufficient randomness (see RFC 
4086 [3]), as noted in Section 3. 


Manually configured keys MUST be used in conformance with RFC 4107 


[4]. Used according to the applicability statement, and with the 
other security measures mandated in this specification, the keys will 
satisfy the properties in that document. In order to ensure 


protection against dictionary attacks, the configured security 
information is intended to be used ONLY for authenticating Binding 
Update messages. 


A mobile node MUST use a different value for Kcn for each node in its 
Binding Update List, and a correspondent node MUST ensure that every 
mobile node uses a different value of Ken. This ensures that the 
sender of a Binding Update can always be uniquely determined. This 
is necessary, as this authorization method does not provide any 
guarantee that the given care-of address is legitimate. For the same 
reason, this method SHOULD only be applied between nodes that are 
under the same administration. The return routability procedure is 
RECOMMENDED for all general use and MUST be the default, unless the 
user explicitly overrides this by entering the aforementioned 
preconfigured data for a particular peer. 


Replay protection for the Binding Authorization Data option 
authentication mechanism is provided by the Sequence Number field of 
the Binding Update. This method of providing replay protection fails 
when the Binding Update sequence numbers cycle through the 16 bit 
counter (i.e., not more than 65,536 distinct uses of Kbm), or if the 
sequence numbers are not protected against reboots. If the mobile 
node were to send a fresh Binding Update to its correspondent node 
every hour, 24 hours a day, every day of the year, this would require 
changing keys every 7 years. Even if the mobile node were to do so 
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every minute, this would provide protection for over a month. Given 
typical mobility patterns, there is little danger of replay problems; 
nodes for which problems might arise are expected to use methods 
other than manual configuration for Kcn and the associated nonces. 
When the Sequence Number field rolls over, the parties SHOULD 
configure a new value for Kcn, so that new Kbm values will be 
computed. 


If a correspondent node does NOT keep track of the sequence number 
for Binding Update messages from a particular mobile node, then the 
correspondent node could be fooled into accepting an old value for 


the mobile node’s care-of address. 
address was reallocated to another 
IPv6 node would then be vulnerable 


In the unlikely event that this 
IPv6 node in the meantime, that 
to unwanted traffic emanating from 


the correspondent node. 


Note that where a node has been configured to use the mechanism 
specified in this document with a particular peer, it SHOULD NOT 
attempt to use another mechanism, even if the peer requests this or 
claims not to support the mechanism in this document. This is 
necessary in order to prevent bidding down attacks. 


There is no upper bound on the lifetime defined for the precomputable 
Kbm. As noted, the key is very likely to be quite secure over the 
lifetime of the security association and usefulness of applications 
between a mobile node and correspondent node that fit the terms 
specified in section 2. 
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